1. Technical Field
The present invention generally relates to a system and method for tracking and synchronizing related data elements in disparate storage systems. More particularly, the present invention provides a system and method for dynamically tracking and synchronizing related data elements stored in disparate storage systems of an enterprise system.
2. Background Art
The efficient and consistent storage of data is a necessary component of successful business. It is common for companies to have large enterprise systems having many storage systems with data replicated there between. Accordingly, when data must be treated (created, moved, modified or deleted) or referenced in one system it is necessary for the data to be similarly treated or referenced in other systems. For example, an insurance company may maintain the name and addresses of its customers in an customer storage system as well as in billing and claims storage systems. As data is created, modified or deleted in the customer storage system, the same changes often have to be propagated in the billing and claims storage systems so the data and storage systems are “synchronized.”
Heretofore, several techniques have been implemented to help solve this problem. One example is known as a “publish and subscribe” mechanism in which one storage system will treat a data element and then instruct other storage systems about the treatment. However, under the “publish and subscribe” mechanism, upon receiving an instruction to treat a data element, the receiving storage system must still locate the data element within its own system. For example, if the claims storage system receives an instruction to modify a particular customer's address, the claims storage system must first determine the location of the particular customer's address within the claims database. Without system-specific identifiers, it may be impossible to locate the storage location of the particular data element. Hence, an additional technique is required to map between system identifiers of the various storage systems.
Another technique is disclosed in U.S. Pat. No. 5,913,061, to Gupta et al., which teaches a collaboration system for defining interaction between applications. The system of Gupta et al. requires that a connector communicate with each application to serve as an intermediary between the application and the collaboration system. However, each connector must store mapping information for its corresponding application, thus, fragmenting the storage of the mapping information among the multiple locations (connectors). By distributing the mapping function to each connector, more burden is placed upon the builder of the connector, and the ability to reuse mapping code (across multiple collaborations) is diminished. Additionally, storing this information in each connector requires that each connector be stateful (have persistent storage associated with it). This also complicates the building and maintenance of connectors. Additionally, the approach of Gupta et al. requires a two step mapping process, first mapping the identifiers from the sending application to the collaboration and then mapping the identifiers from the collaboration to the receiving application. This is less efficient than directly mapping sending application identifiers to receiving application identifiers. Additionally, the system of Gupta et. al. requires that all communication between applications be reformatted by the connectors into the format of the collaboration system. This can be redundant and inefficient if the systems to be integrated and synchronized already make use of a standard protocol and the only translation needed is to map application identifiers from one application to another.
Still other systems have used a cross-reference facility whereby each data element is associated with a record identifier for each system in which the data element is stored. Thus, when a change is made at one system, the system will inform the other systems of the change. However, this requires that all systems maintain a table or the like indicating where the data element is stored on all other systems. Moreover, complications can arise when there is not a one-to-one correspondence between records in each system. For example, a customer's contact information may be stored in one record in the claims storage system, but in three records in the billing storage system. Thus, the amount of information that each storage system must maintain is increased.
In view of the above, there exists a need for a system and method for dynamically tracking/synchronizing related data elements in disparate storage systems. Moreover, there exists a need for such a system and method that does not require each storage system to maintain high volumes of storage information for the other systems. In addition, there exists a need for such a system and method that does not require re-formatting of communication between storage systems. There also exists a need to provide these functions as a re-usable centralized service that is efficient and avoids multiple translations between identifiers.